The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
In client-sever systems that include authorization of clients, it is important to maintain accounting information for the clients that are authorized to access the system. In a typical system, a client attempts to connect to a network device (e.g., a wireless access point) and an authentication and authorization protocol is initiated. The network device requests credentials, which the client then supplies. The credentials are passed to an authentication, authorization, and accounting (AAA) server, which looks up additional information on the client to make a decision about the whether the client should be granted access.
After making the decision, in implementations that use the Remote Authentication Dial In User Service protocol (RADIUS) protocol, the AAA server returns an access accept message, an access reject message, or ‘silently discards’ the request if it is invalid. If an access reject message is returned, then the client is denied access. If an access accept message is returned, then the client is granted access and the network device sends the AAA server a session start record which the AAA server writes to its logs.
When the client's session ends, the device generates an accounting stop record which it sends to the AAA server to write to its logs.
A problem with such systems, however, is that they do not keep track of the reason why a client was accepted or rejected by the AAA server. This is important for a number of reasons, including aiding system debugging and identifying fraudulent users, analysis, audit, and reporting.
Historically, this problem was partially resolved by the logging service provided by some AAA servers running RADIUS or Terminal Access Controller Access Control System protocol (TACACS+) and was deemed adequate for the requirements of the network administrators running the network access service. In part, this was sufficient because the AAA server architecture was a relatively simple two-tier client/server application with access to all user information in its own database. This meant that the AAA server was able to log any additional data already stored within its own database relatively easily by injecting the extra data into the AAA accounting packets as they passed through that server. This methodology required that the same AAA server that granted authentication also processed the accounting packets for the corresponding session. This methodology also required the AAA server to cache the information that was used to make the authorization decision.
Now, however, AAA servers often need to access one or more external identity repositories to get the data needed to make an authentication decision, and a number of AAA servers may be load balanced and thereby share the AAA processing workload. For example, Lightweight Directory Access Protocol (LDAP) directories may hold needed user identity data. In addition, driven by increasingly rigorous security requirements, there is a need for richer audit and accounting record logging. In these systems, the ‘raw’ data provided by the network device via RADIUS accounting is insufficient and must be augmented with additional identity related information, for example:
The entity's (user or device) real name and department code
The entity's group membership (within the corporate repository and/or the AAA server)
Other policy data known by the AAA policy server at authentication time (e.g. applied role, policy and provisioned profile name)
Such identity-related information is not held by the AAA server, but, instead, is retrieved from external repositories when required to service incoming the authentication and authorization components of AAA requests. As noted above, this data is needed for later logging, but since the data is not local, a solution is needed for retaining or re-retrieving this information.
In one possible approach, the data is cached locally at the AAA server. One problem with this approach is that caching the data limits load balancing of AAA servers and would require the AAA server to keep state for each client session. That is, if the AAA server cached all required information, then the RADIUS accounting messages, also known as Call Data Records (CDR), would then have to be routed through the same AAA server that performed the authentication.
In another approach, the AAA server would have to fetch the additional information a second time, and possibly more times, in order to augment logging records. The problem with this approach is that it at least doubles the load on the external repository being imposed by the AAA server and the network traffic required to service that load.
Another problem with both of these approaches is that the AAA server must investigate, i.e. parse and interpret, each incoming message to determine whether it needs to be augmented with additional accounting information. This would unduly increase the processing burden on the AAA server.
Based on the foregoing, there is a clear need for a solution that can enable accounting of authorization decision and other accounting information without requiring state on or additional data-fetching by the AAA server, while still allowing AAA server load-balancing.